Addresses issues from Remco's environment testing.

BEAUti and `applauncher LogAnalyser` failed with
ClassNotFoundException for beast.fx classes (BeautiConfig and the input
editors). Root cause: a package's service providers are listed in its
version.xml; when a version.xml scan registered a provider (via
resolveLoaderFor) before the owning beast.fx plugin ModuleLayer existed,
the provider was mapped to the fallback system loader, which cannot load
it. registerPluginLayer uses putIfAbsent and so could not replace the
stale mapping, so BEASTClassLoader.forName threw.

  - forName now falls through to the plugin layers on ClassNotFoundException
    from the mapped loader, and caches the loader that actually resolves the
    class (self-healing, so the slow path runs at most once per class).
  - resolveLoaderFor now also consults registered plugin layers, not just
    the boot layer.
  - Added a regression test reproducing the stale-mapping scenario.

`beast -version` listed BEAST.base twice (once from the user package
dir, once via the bundle-root version.xml that the install dir
contributes). printVersion (both the beast-base and beast-fx copies) now
lists each package once, noting where it was found, and reports later
duplicates as skipped only in verbose mode.

BEAST.base examples could not be updated by a point release: they shipped
only in the bundle root, which is replaced only by a full reinstall. The
BEAST.base package zip now includes examples/ (curated to match the
bundle), so the package manager extracts and updates them in
~/.beast/2.8/BEAST.base/examples on install/upgrade. The three release
scripts (Linux/Windows/Mac) now extract the bundle-root examples from
that same package zip, giving the example set a single source of truth
(beast-base/src/assembly/package.xml) so the copies cannot drift.